home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 12⁄1⁄89 / 0384-Instantiation “by cl-Jan90 < prev    next >
Encoding:
Text File  |  1990-01-12  |  2.3 KB  |  56 lines  |  [TEXT/GEOL]
  1. Item    8843225                         11-Jan-90        00:14
  2.  
  3. From:   FALK2                           Austria - Alexander Falk
  4.  
  5. To:     MACAPP.TECH$                    MacApp Technical
  6.  
  7. Sub:    Instantiation “by classname”?
  8.  
  9. Hi,
  10.  
  11.   This is a purely “philosophical” question, but it is somehow connected with
  12. the previous discussion on cloning in MacApp.
  13.  
  14.   Can anyone enlighten me, why there is a need to instantiate an object “by
  15. classname” in MacApp? I’m talking about the RegisterStdType("TWhateverView"...)
  16. procedure, where you tell MacApp about your new view class, so that it can
  17. later create an object of that class to show it in your document (see
  18. UNothing.cp).
  19.  
  20.   In my opinion this technique has several drawbacks:
  21.  
  22.     •) It is NOT a very nice OOP technique.
  23.  
  24.     •) The linker doesn’t know that this class is actually used and tries
  25.        to dead-strip it’s code, so there is need for the “gDeadStripSuppresion”
  26.        trick (which is VERY kludgy).
  27.  
  28.     •) This very “gDeadStripSuppresion” trick can create a lot of confusion for
  29.        people, who have previously used OOP languages, but haven’t used MacApp
  30.        before. For example I suspected that gDeadStripSuppression would always
  31.        be true, until this problems was fixed. And so I was very surprised,
  32.        that in the C++ sample the object created there was never actually being
  33.        deleted again (I know, I should have read the manual....).
  34.  
  35.   Wouldn’t it be simpler if instead of calling RegisterStdType("classname"...)
  36. in the IWhateverApplication the application object would instantiate an object
  37. for that special view class itself and pass it to MacApp. MacApp could then
  38. easily clone this object whenever it needs one (now we are back at the previous
  39. discussion on how to clone an object).
  40.  
  41.   This might be a way more coherent with the OOP paradigm than the current
  42. technique. And it would immediately solve the problem of preventing the linker
  43. from dead-stripping the methods of this class! So instead of calling
  44. RegisterStdType( "\pTWhateverView", ... ) in the future you’d write
  45.  
  46.     TWhateverView* MyView = new TWhateverView;
  47.     RegisterStdType( MyView, ... );
  48.  
  49.   Am I being too simpleminded here and do I overlook some sideeffects or
  50. special benefits of the current technique of instantiation “by classname”?
  51.  
  52. Regards,
  53.  
  54. Alexander Falk
  55.  
  56.